Colour Alone on Focus — Known Limitations
When a control shows that it has keyboard focus by changing colour and nothing else, people who cannot distinguish that colour change have no way of knowing where they are on the page. This check looks for that situation.
This page is the honest list of what the check does not catch today. If you are reviewing results and a case falls into one of these categories, the tool was never going to report it — it is a known gap, not a missed issue.
How the check behaves
The check looks at every control that already passes 2.4.7 Focus Visible — that is, controls that visibly react to focus in some way. It compares how the control looks unfocused against how it looks focused.
If the only perceptible difference is a change of colour — background, border, outline, text or icon colour — and the two colours are less than 3:1 apart, the control is reported. If the focus state also brings a non-colour cue (a ring appearing, a border thickening, an underline), the control passes.
Two assumptions underpin that approach, and almost every limitation below follows from one of them:
- The focus indicator is drawn on the control itself, not on something inside it.
- The colour can be read as a single solid colour in one still image of the page.
What the tool does report
A solid colour change on the control itself — background, border, outline, text colour, icon fill or stroke — that measures under 3:1 against the unfocused state and comes with no other visual cue. Semi-transparent colours are included: the tool composites them over what is behind them before measuring.
If a case looks like that and does not come out in the report, it is a genuine missed issue.
What the tool does not report today
1. The indicator is drawn on something inside the control
The focus effect is painted on a child element rather than on the button or link itself. This is the standard pattern in Material Design, where a translucent "state layer" sits inside the control.
The check only looks at the control that receives focus, so a change living one level down is invisible to it.
Seen on: marinasmarlin.com/home/experiences (Mission/Vision controls, header login, search icon), tiendascaracol.com (cart icon).
2. The indicator is an animation or a ripple
The focus cue is a moving effect — a ripple expanding out from the control — and it usually also lives on a child element. The page is held still before measuring so that animations do not blur the comparison, which means the ripple is not there to be seen.
Treating "there is an animation" as a reason to skip the control is not an option: nearly every modern component has decorative transitions, and that rule would switch off most of the check.
Seen on: avantstay.com (collection carousel cards), where the tool currently reports a false positive of 1.22:1 on the active slide.
3. The focus ring is part browser, part site
The outline takes its thickness from the browser's own default and only its colour from the site's stylesheet. Because a browser-drawn ring appears, the tool treats the control as having a valid non-colour cue and moves on.
Colours written using newer CSS colour-mixing notation are also not resolved.
Seen on: sercotelhoteles.com/es (booking controls — dates, guest and room selector).
4. Opacity, in most of its forms
Opacity behaves inconsistently here, which explains why the same kind of case is sometimes caught and sometimes not:
| How the opacity is applied | Result |
|---|---|
| A translucent background colour on the control itself getting slightly stronger on focus | Reported. This is a genuine background colour change and is measured against what is behind it |
| A background going from fully transparent to a visible fill | Not reported as 1.4.1 — a new element is appearing rather than an existing colour changing, so it is classified under 1.4.11 instead |
| The control's own opacity going from faded to solid | Not reported. Fading a button also fades its text and its icon, so more than one thing changes at once and the case falls outside what the check evaluates |
| Opacity on a parent container, affecting the control through it | Not reported — the check looks at the control, not its ancestors |
| Opacity inside a decorative pseudo-element | Not reported (see §6) |
5. Translucent colours over an unknown background — partly solved
Translucent indicators used to produce a meaningless result. The tool now blends the translucent colour over whatever is behind it before measuring, and the report shows both the real value and the blended approximation.
What remains: when only a border or outline changes, the tool cannot always work out what is behind it and falls back to assuming white. That is right when the control sits on a light background and wrong when it sits on a dark one. When the background is an image, the case is skipped rather than guessed at.
Seen on: acubaenvioscargo, which now measures 1.13:1 instead of a false 1.00:1.
6. Gradients and decorative pseudo-elements
If the focus style is a gradient, there is no single colour to measure — sampling it gives approximate values that can land on either side of the threshold from one run to the next.
If the focus style is drawn on a decorative pseudo-element (::before / ::after), the comparison does not reach it at all.
Seen on: havanaship.net, which uses both together.
7. The background changes as you scroll
Some controls sit over a background that changes with the scroll position — a hero image at the top of the page that becomes white further down, or a sticky bar that changes colour.
This is only a limitation when the verdict depends on that background. Focus changes that affect text colour or a border are measured colour against colour and do not care what is behind them; those are reported correctly no matter where the page is scrolled. It is translucent colours and background-colour changes that get composited over the background, and there the tool captures one moment only — and skips the case entirely when the background is an image.
Seen on: havanaship.net — the "Inicio" link changes text colour (1.29:1) and is correctly reported, while the hero button over a background image is skipped.
8. Focus that only appears with a real Tab press
Some controls reveal their focus style only when a person actually presses Tab, and show nothing when focus is applied any other way. These are hard to reproduce and inspect by hand, and the tool does not see them either.
Seen on: transtur.net (FAQ arrow control), tiendascaracol.com (cart icon).
9. Pages the tool cannot reach properly
- Sites that block automated visitors. Tab does not move focus, no controls are collected, and nothing can be analysed. Example: grainger.com.
- A fixed overlay covering the control. When a floating panel mounts over the control during scrolling, the capture picks up the overlay instead. Example: theknowledgeacademy.com ("Send enquiry") — the control's focus style does change; it was confirmed by hand after closing the overlay.
10. Two colours changing at once
If focus changes two colour properties on the same control — say both the border and the text, or both the border and an icon — the case falls outside what the check evaluates and nothing is reported.
This applies when both changes are part of the control and carry meaning. A control whose only second change is a decorative dropdown arrow is still analysed.
Cases the tool currently over-reports
Two patterns produce false positives today, and are being handled separately:
- A single colour change plus an animation or ripple — the ripple is the real indicator, but the tool does not see it and reports the colour.
- A single colour change plus additional content appearing (a dropdown, tooltip or popover) — the new content is the real cue.
Quick reference for reviewers
Do not file a missed issue when the control falls into any of these:
- The colour change lives on a child element (Material state layer, inner span)
- The outline combines browser thickness with a site colour, or uses colour mixing
- Opacity on an ancestor or inside a pseudo-element
- A gradient is used as the focus style
- The focus style is drawn on a pseudo-element
- The background behind the control changes with scroll
- The site blocks automation, or an overlay covered the control
- The indicator is an animation or ripple
- Two colour properties change at once
Do file a missed issue when: a solid colour changes on the control itself — background, border, outline, text, icon fill or stroke — including translucent colours, the contrast is under 3:1, and there is no non-colour cue.
WCAG reference
Success Criterion 1.4.1 Use of Color (Level A)